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P ersistence, this one word causes more grief 
and costs more ti me i n terms of system devel - 
opment with objects than any other single is¬ 
sue In theory, the problem isaverysimpleone 
Is there a way for an application to store and retrieve 
the data contained within its objects? 

Will the persistence mechanism also maintain the 
relationships between the objects in addition to the 
raw data? Will it support object identity properly? 
And how fast (slow) will it execute? 

Provi d i ng a sui tabl e answer for al I of these questi ons 
is extremely difficult. Persistence has always been an 
issue with object-oriented languages, Smalltalk being 
no exception. The first persistence mechanism de¬ 
signed for Smalltalk used the 
storeOn: method to ask an object 
to generate a string that, when 
evaluated, would return the ob- 
ject itself. Clever idea, butnotvery 
practical.Thenextideawasto use 
a Loader/Dumper style implementation, where an 
entire object (and all its parts) can be stored in a file; 
and later retrieved. This worked well as far as it went. 
The shortcoming was that an object being retrieved 
had no notion of the relationships it used to have 
with other objects, and vice versa. And it certainly 
did not scale in terms of sizeor maintenance. 

The correct solution, of course, isto useatrue data¬ 
base of some flavor. Be it IM S, Oracle; Sybase, Gem¬ 
stone, Versant, etc., the idea is to store and retrieve 
objects using a faci I ity designed to do just that. 

So, what’s so hard about this? As most of you know, 
thedifficult part isnotthe"datef'stored with theobject. 
It is simple to store and retrieve data such as a name; 
phone number and date of bi rth of a customer object. 
The difficulty comes in maintaining the relationships 
between the objects as designed in our systems. For 
example, our customer object may have a reference to 
an account object (or many) as well as relationships 
with other customers (a bank would keep track of our 
relationship with our spouses). The challenge is how 
keep track of these types of rel ati on sh i ps? An d how can 
we support the dynami c nature of these relati onsh i ps? 

The quick answer, of course, is to use an object per¬ 
sistence storage mechanism. Tools such as GemStone, 
Versant, and others handlethese complex and dynam¬ 
ic relationships with next to no effort. There are other 
issues to consider when deciding whether or not to 
employ these new persistence mechanisms, but ease 


of managing these relationships isn't one of them. 
However, most of us aren’t in the position to entertain 
such a choice (and maybe we shouldn't anyway). Our 
organ i zati ons have i nvested si gn ifi cantly i n other tech¬ 
nologies that serve the overall organization quite well. 
Furthermore, since the data used by our Smalltalk 
applications is often shared with others, a more tradi¬ 
tional route may be theonlypractical choice. 

Using a relational mechanism poses some signifi¬ 
cant chal I enges. For example, determi n i ng how to map 
the relationships found in ourobject model to tables is 
nontrivial. The greater the difference between the ob¬ 
ject model to the data model, the more difficult the 
mappings can become. For example, many-to-many 
relationships (customers to ac¬ 
counts) require an intermediate 
table in the relational world, but 
in the object world, they’re really 
a nonissue. Storing and retriev¬ 
ing objects from non-relational 
mechanismsisprovingtobeeven more difficult. Many 
relationships that exist in objects are virtually impos¬ 
sible to duplicate in, for example, a CICS transaction. 

Having stated the difficulties, many have been able 
to successfully bridge the worlds. Most of these solu¬ 
tions are "home-grown." Our concern with home 
grown solutions isthateven once we descri be how to 
overcome the hurdles and discover the mappings re 
qu i red, we’re sti 11 faced with two si gn i fi cant chal I enges. 
First, the execution speed can often be painful (espe 
dally with writes) if not very careful about the database 
commands generated (eg., SQL statements or stored 
procedures). Second, and more important, isthe effort 
that is required to maintain the mappings. 

This point concerning maintenance is being over¬ 
looked by far too many shops who are building their 
own interfaces. Many are saying "I can build it myself" 
and they can. But the impact on the elegance of the 
implementation is going to lead to systems that are 
tougher to extend and difficult to understand. What 
many seem to fai I to grasp is, even if they can under¬ 
stand it while they’re writing the code; will the person 
coming behind them to maintain it be able to under¬ 
stand? And what about the person behind them?The 
real costs of our solutions will be seen down the road. 
We strongly believe it is our job as software engineers 
to desi gn systems that are easy to mai ntai n—if we fai I, 
we haven’t doneour organ izati ons any favors 
Enjoy the issue. 


It is our job to design 
systems that are easy 
to maintain. 
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